home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9792 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB

  1. Path: dawn.mmm.com!news
  2. From: kjhopps@mmm.com (Kevin J Hopps)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Placement new = reconstruction?
  5. Date: 4 Mar 1996 15:25:07 GMT
  6. Organization: 3M - St. Paul, MN  55144-1000 US
  7. Message-ID: <4hf20j$69q@dawn.mmm.com>
  8. References: <4h4hn5$k8c@clarknet.clark.net>
  9. Reply-To: kjhopps@mmm.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Harlan Messinger (gusty@clark.net) wrote:
  13. > Do I understand correctly that placement new allows for reinitialization 
  14. > of an object in place, thereby giving two advantages:
  15.  
  16. >     -- elimination of time spent repeatedly allocating and 
  17. >         deallocating, and
  18.  
  19. >     -- elimination of concern over proper destruction?
  20.  
  21. > In other words, if I have a class Bar that itself performs no allocation, 
  22. > and I need to perform an operation on a series of Bar objects, instead of 
  23. > allocating a new Bar object for each iteration, can I do the following? Is 
  24. > there any reason I shouldn't?
  25.  
  26. _IF_ Bar performs no "allocation," and
  27. _IF_ Bar contains no members with destructors, and
  28. _IF_ you are sure that Bar will never be changed to perform allocation, and
  29. _IF_ you are sure that Bar will never be changed to contain members with
  30. destructors, then you are probably safe to construct a Bar repeatedly without
  31. destroying it between constructions.
  32.  
  33. I put "allocation" in quotes because it is not only calls to new that you
  34. need to be aware of.  It is any resource allocation or any change in the
  35. program state which will accumulate with multiple constructions of a Bar.
  36. This would include things such as opening files or even incrementing a
  37. static counter.
  38.  
  39. > Finally, is "placement delete" (i.e., a direct call to bar_->~Bar())
  40. > required before each placement new, or before bar_ goes out of scope, or
  41. > is it optional if Bar doesn't dynamically allocate anything and therefore
  42. > doesn't need to DEallocate anything? 
  43.  
  44. It is optional even if Bar does allocate things.  There are no C++ police
  45. to give you a ticket for not calling a destructor.  :-)
  46.  
  47. >     class Bar
  48. >     {
  49. >     public:
  50. >         Bar(const char *stringArg = NULL);
  51. >         ~Bar() {}
  52. >         void doit();
  53. >     };
  54.  
  55. >     Bar::Bar(const char *stringArg) { /* whatever */ }
  56. >     void Bar::doit() { / * whatever */ }
  57.  
  58. >     class Foo
  59. >     {
  60. >     private:
  61. >         Bar bar_; // So bar_ will be destroyed automatically 
  62. >                 // when Foo is.
  63. >     public:
  64. >         Foo() {}
  65. >         ~Foo() {}
  66. >         void run(const char *stringArg = NULL);
  67. >     };
  68.  
  69. >     void Foo::run(const char *stringArg)
  70. >     {
  71. >         new &bar_ Bar(stringArg);
  72. >             // Instead of deallocating and reallocating,
  73. >             // just create the new version of bar_ in place.
  74. >         bar_.doit();
  75. >         return;
  76. >     }
  77.  
  78. You seem to going to extremes (and making many assumptions about the Bar
  79. class) to avoid calling ~Bar().  Why?
  80.  
  81. In your example, the destructor is inline, and does nothing.  The compiler
  82. should optimize away any calls to it.  Further, if Foo::run is the only
  83. place you use the Bar, why not make it local to that function instead of
  84. making it a member of Foo?
  85. --
  86. Kevin J. Hopps                  e-mail: kjhopps@mmm.com
  87. 3M Company                      phone:  (612) 737-4643
  88. 3M Center, Bldg. 235-2D-57      fax:    (612) 737-2700
  89. St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
  90.     But 3M speaks for me -- I did not write the following line:
  91.  
  92. Opinions expressed herein are my own and may not represent those of 3M.
  93.